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Abstract 


Rule-based  systems  are  being  applied  to  taslvs  of  increasing  responsibility.  Deductive  meth¬ 
ods  are  being  applied  to  their  validation,  to  detect  flaws  in  these  systems  and  ena])le  us  to 
use  them  with  more  confidence. 

Each  system  of  rules  is  encoded  as  a  set  of  axioms  that  define  the  system  theory.  The 
operation  of  the  rule  language  and  information  about  the  subject  domain  are  also  described 
in  the  system  tlieory.  Validation  tasks,  snclr  as  establishing  termination,  unreachability, 
or  consistency,  or  verifying  properties  of  the  system,  are  all  phrased  as  conjectures.  If  we 
succeed  in  establishing  the  validity  of  the  conjecture  in  the  system  theory,  we  have  carried 
out  the  corresponding  validation  task. 

If  the  proof  is  restricted  to  be  sufficiently  constructive,  we  may  extract  from  it  infor¬ 
mation  other  than  a  simple  yes/iio  answer.  For  example,  we  may  obtain  a  description  of  a 
situation  in  which  an  error  or  anomaly  may  occur. 

A  method  for  the  gradual  formulation  of  specifications  based  on  the  attempted  proof 
of  a  series  of  conjectures  has  been  found  to  be  suitable  for  rule-based  systems.  Such  a 
specification  can  serve  as  the  basis  for  a  reengineering  of  the  system  using  conventional 
software  technology. 

Validation  conjectures  are  proved  or  disproved  by  a  new  theorem-proving  system,  SNAR,K, 
which  implements  (nonclaiisal)  resolution  and  paramodulation,  an  optional  constructive  re¬ 
striction,  and  some  facilities  for  proof  by  induction.  The  system  has  already  been  applied 
to  prove  properties  of  a  number  of  simple  rule-based  systems. 

1  Introduction 

Languages  based  on  rules  are  an  appealing  implementation  vehicle  for  expert  systems.  The 
system  can  be  developed  incrementally  without  much  preliminary  planning.  In  introducing 
a  new  rule,  one  snp])Osedly  need  have  little  understanding  of  how  the  rest  of  the  system 
behaves.  The  rules  may  embody  the  advice  of  many  different  experts,  who  are  ignorant 
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of  eacli  other’s  opinions  and  may  even  disagree  with  each  other.  Proponents  of  rule-based 
methodologies  have  found  that  they  can  develop  running  systems  far  more  quickly  than 
with  conventional  programming  languages. 

As  a  consequence  of  this  success,  expert  systems  based  on  rules  have  been  proposed  for 
tasks  of  increasing  responsibility,  including  aircraft  and  spacecraft  fault  diagnosis  as  well  as 
financial  and  medical  advice.  For  this  reason,  the  question  arises  of  how  we  can  establish 
that  these  systems  will  be  worthy  of  our  confidence? 

This  is  where  a  conflict  emerges.  Accumulated  experience  suggests  that  to  be  trust¬ 
worthy,  a  system  must  be  constructed  in  a  systematic  way  that  begins  with  an  attempt  to 
formulate  its  specification  prior  to  the  implementation  effort.  This  doctrine  is  antithetical  to 
the  rule-based  system  methodology,  in  which  the  intended  behavior  of  the  system  changes  at 
each  stage  of  its  implementation.  The  system  is  developed  in  the  absence  of  specifications; 
in  fact,  the  methodology  may  be  regarded  as  a  framework  for  rapid  prototyping,  in  which 
we  gradually  formulate  an  executable  specification  through  experimentation.  On  the  other 
hand,  a  complex  nondeterministic  system  of  rules  is  rarely  acceptable  as  a  specification;  it 
is  difficult  for  anyone,  including  its  developers,  to  predict  what  it  will  do. 

It  is  not  the  purpose  of  this  paper  to  criticize  or  improve  the  rule-based  system  method¬ 
ology.  Rather,  we  shall  attempt  to  apply  deductive  techniques  to  support  the  methodology 
as  it  is  practiced.  We  shall  provide  techniques  to  determine  what  a  rule  system  does,  to 
identify  its  faults,  and  to  establish  confidence  in  it.  One  may  be  able  to  formulate  a  single 
specification  that  characterizes  the  intended  behavior  of  the  system.  That  specification  may 
then  be  used  as  the  basis  for  a  reimplementation  of  the  system  using  conventional  software¬ 
engineering  techniques.  We  may  hope  that  the  reimplemented  system  will  be  more  efficient, 
concise,  and  reliable  than  the  original. 

In  other  cases,  in  which  the  system  is  too  complex  to  allow  a  full  specification  to  be 
verified  or  even  formulated,  we  can  use  deductive  methods  to  assist  in  the  testing  of  the 
system.  We  can  generate  sets  of  test  cases  that  e.xercise  all  tlie  rules  of  the  system  or  that 
cause  certain  inconsistencies  or  anomalies  to  occur.  We  can  detect  that  certain  rules  will 
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never  be  executed.  The  same  deductive  framework  can  serve  a  variety  of  these  purposes. 

Because  rules  look  like  logical  sentences,  it  is  tempting  to  treat  them  that  way,  and 
analyze  tliem  for  properties  such  as  consistency.  In  fact,  rules  cannot  usually  be  understood 
in  a  purely  declarative  way.  They  are  imi)evative  constructs  with  the  intended  side  effects  of 
adding  elements  to  and  deleting  tliem  from  a  single  data  structure,  the  “working  memory.” 
In  this  paper,  we  treat  a  rule  language  as  an  imperative  language.  Because  all  side  effects 
in  the  language  alter  a  single  structure,  the  language  is  more  amenable  to  logical  analysis 
than  most  imperative  languages,  such  as  those  with  general  assignment  statements. 

Special  problems  arise  because  of  the  nondeterministic  nature  of  rule-based  languages. 
A  situation  can  occur  in  which  more  than  one  rule  is  applicable,  and  the  system  implemen¬ 
tation  must  choose  between  them.  Different  implementations  may  make  different  choices 
and  a  system  may  behave  correctly  in  one  implementation  and  not  in  another.  It  may  be 
difficult  to  anticipate  what  different  implementations  may  do. 

Conventional  program  verification  often  assumes  that  a  full  specification  for  a  correct 
system  is  available.  In  this  work,  we  recognize  that  the  system  may  be  incorrect  and 
the  specification  may  be  only  partial.  We  detect  faults  and  formulate  the  specification 
gradually,  as  a  result  of  attempts  to  prove  a  series  of  conjectures  about  the  system.  We 
may  also  attempt  to  prove  the  conjecture’s  negation,  which  will  hold  if  the  system  fails  to 
possess  the  desired  property. 

In  most  work  on  program  verilicatioii,  a  proof  gives  us  at  best  a  yes/no  answer  as 
to  whether  a  system  meets  its  specification.  Implicit  within  a  proof,  however,  is  other 
potentially  valuable  information,  which  is  usually  discarded.  For  example,  if  we  prove  the 
existence  of  a  fault  in  a  system,  we  may  be  able  to  extract  from  the  proof  a  description  of 
the  conditions  under  which  that  fault  occurs.  Program  synthesis  techniques  for  extracting 
programs  from  constructive  proofs  (e.g.,  Mauna  and  Waldiiiger  [9])  may  also  be  applied  to 
extract  other  sorts  of  information. 
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1.1  Validation  Tasks 


In  ]<eeping  with  these  goals,  we  consider  a.  variety  of  validation  tasks,  most  of  which  have 
both  a  positive  and  a  negative  aspect. 

•  (+)  Verification:  Proving  that  a  system  will  always  satisfy  a  given  condition. 

(— )  Fault  detection:  Exhibiting  an  input  that  causes  a  system  to  fail  to  satisfy  a  given 
condition. 

•  (+)  Termination:  Proving  that  a  system  will  always  terminate. 

(— )  Loop  detection;  Exhibiting  an  input  that  will  cause  a  system  to  fail  to  terminate. 

•  (+)  Firing:  Exhibiting  an  input  that  causes  a  given  rule  to  fire. 

(  — )  Unreachability:  Proving  that  no  input  will  cause  a  given  rule  to  fine. 

•  (+)  Consistency:  Proving  that  no  input  can  produce  an  inconsistent  working  memory. 

(— )  Inconsistency:  Exhil)iting  an  input  that  will  produce  an  inconsistent  working 
memory. 

Some  of  these  problems  are  significantly  more  difficult  than  others.  For  example,  to  prove 
that  a  system  always  terminates  will  generally  require  considering  all  execution  histories 
beginning  from  any  2:)ossible  input,  at  least  in  principle.  Exhibiting  an  input  that  causes 
Rule  A  to  fire  may  require  considering  a  small  number  of  inputs  and  only  part  of  the  system. 
Thus,  we  can  expect  to  be  successful  at  this  smaller  task  more  readily  than  at  e.stablishing 
termination. 

1.2  The  System  Theory 

Our  approach  is  deductive.  For  a  given  system  of  rules,  we  develop  a  system  theory,  which  is 
defined  by  a  set  of  a.xioms  that  express  the  actual  behavior  of  the  system.  The  system  theory 
also  incorporates  any  background  knowledge  we  wish  to  take  into  account  in  validating  the 
system.  For  each,  validation  task,  there  is  an  associated  conjecture.  If  we  can  manage 
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to  establish  the  validity  of  the  conjecture  in  the  system  theory,  we  have  performed  the 
associated  validation  task.  Typically,  to  perform  the  negative  aspect  of  a  task,  we  prove 
the  negation  of  the  conjecture  associated  with  its  positive  aspect.  If  we  want  to  exhibit 
an  input  or  other  object  as  part  of  our  task,  we  must  restrict  the  proof  syntactically  to  be 
sufficiently  constructive;  this  means  that  the  proof  will  tell  us  how  to  build  such  an  object. 
The  descrijjtion  of  the  object  can  then  be  extracted  from  the  proof  automatically. 

1.3  Related  Work 

There  have  treen  several  efforts  to  apply  conventional  testing  techniques  to  rule-based  sys¬ 
tems  (e.g.,  Becker  et  al.  [1],  Kiper  [8]).  The  body  of  work  closest  to  ours  is  that  of 
Chang,  Combs,  and  Stachowitz  [11,  4,  5]  at  the  Lockheed  Artificial  Intelligence  Center. 
The  Lockheed  work,  like  ours,  deals  with  some  specifications  of  the  expected  properties 
of  the  rule-based  system  and  uses  deductive  methods  to  establish  them.  It  uses  Prolog  as 
an  inference  system,  which  limits  it  to  properties  expressed  as  Horn  clauses.  The  SNARK 
theorem  prover  we  are  developing  accepts  properties  in  a  full  first-order  logic,  with  mathe¬ 
matical  induction.  Unlike  most  researchers,  we  deal  with  rules  that  may  delete  as  well  as 
add  elements  of  the  working  memory.  Our  work  is  also  original  in  that  it  presents  a  unified 
theoretical  framework  for  expressing  and  establishing  properties  of  rule- based  systems. 

1.4  Outline  of  this  Paper 

We  first  provide  a  description  of  a  somewhat  idealized  rule  language  in  Section  2.  For  a  given 
system  of  rules,  we  show  how  to  construct  a  corresponding  system  theory  in  Section  3  and 
in  Section  4  how  to  translate  validation  tasks  into  conjectures  in  the  theory.  In  Section  5, 
we  exhibit  portions  of  a  validation  proof  and  present  a  scenario  leading  to  the  fornmlation 
of  a  specification  for  a  textbook  rule-based  system.  Finally,  in  Section  6  we  describe  the 
SNARK  theorem  prover  we  have  been  developing  to  prove  validation  conjectures  and  to 
extract  inforniation  from  validation  proofs. 


2  Rule-Based  Systems 


In  this  section  we  present  a.  prototy])e  rule-based  system  framework  that  will  serve  as  the 
focus  of  our  effort. 

2.1  The  Rule  Language 

Our  rule  language  is  a  sinootlied-up  version  of  0PS5  [7,  3].  A  rule  describes  an  opera¬ 
tion  to  be  performed  on  working  memory.  Tlie  working  memory  is  a  (finite)  set  of  atoms 
p(/.i, . . .  where  p  is  a  predicate  s\''mbol  and  /i,...,/.;..  {k  >  0)  are  terms.  The  atoms 
in  working  memory  are  ground^  that  is,  thej'  contain  no  varialrles,  only  constant,  function, 
and  predicate  symbols.  An  atom  p{)  with  no  arguments  will  be  written  p.  For  example, 

{far7ner{jolin),  banke7'{moilier {joint))} 

is  a  working  memory. 

A  rule  is  an  e.xpression  of  tire  form 

Ij\  ,  .  .  .  ,  I-fyjl  ^  ,  .  .  .  ,  Ibyi 

Here  each  element  Li  of  the  left  side  is  a  literal,  that  is,  either  an  atom  p(fi .,ti;)  or  the 
negation  not  p{ti,.-  -  Ttk)  of  an  atom.  Each  element  Ri  of  the  right  side  is  an  (unnegated) 
atom.  We  do  not  require  rule  elements  to  be  ground,  that  is,  they  may  contain  variables. 
For  example 

7’ed(,r),  not  big{x)  — ^  blue{x) 

is  a  rule.  We  impose  certain  restrictions  on  rules;  these  will  be  discussed  after  we  have 
described  rule  application. 

2.2  Rule  Application 

To  apply  a  rule  to  working  memory,  we  first  select  a  ground  instance  of  the  rule,  that 
is,  we  replace  each  of  its  variables  with  a  corresponding  ground  term.  We  require  that  the 
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instances  of  the  positive  (unnegated)  atoms  on  the  left  side  of  the  rule  be  present  in  working 
memory  and  that  the  instances  of  the  negated  atoms  be  absent. 

For  example,  tlie  rule 

Rule  B  :  red(x),  not  l}i<:j{x)  — i-  blue{x) 
is  applicable  to  the  working,  memory 

{red{b),big{a)}. 

The  appropriate  rule  instance  is  obtained  by  replacing  .r  with  the  ground  term  b.  The 
instance  red(b)  of  the  positive  atom  red{x)  is  present  in  this  working  memory;  the  instance 
big{b)  of  the  negated  atom  bi(j{x)  is  absent. 

To  apply  an  applicable  rule  to  the  working  memory,  we  delete  the  selected  instances  of 
the  positive  atoms  of  tlie  left  side  and  add  the  instances  of  the  atoms  of  the  right  side.  For 
example,  to  apply  linle  B  to  the  working  memory  we  delete  red{b)  and 

add  iiwe(fc),  to  obtain  the  new  working  memory 

{blue{b),bi(){a)}. 

Note  that  instances  of  the  positive  atoms  on  the  left  side  are  deleted  as  the  rule  is 
applied.  This  means  that  if  any  of  these  atoms  is  to  be  retained,  it  must  appear  on  the 
right  side  as  well,  so  that  it  can  be  added  back  into  working  memory. 

For  example,  the  rule 

ved[x),bi(j[x)  — j-  blue{x) 

will  delete  instances  of  both  Ted{x)  and  big{x)  from  working  memory.  If  it  is  intended  that 
the  rule  retain  the  instance  of  big{x),  the  rule  must  read 

red{x),big{x)  — blue{x),big{x). 

(Tills  rule  describes  a  situation  in  whicli  big  red  blocks  are  to  be  painted  blue,  but  remain 
big.)  The  rationale  for  this  convention  is  that  the  positive  atoms  of  the  left  side  are  replaced 


in  working  memory  by  the  atoms  of  the  riglrt  side;  thus  the  ride  beliaves  as  a  rewriting  of 
working  memory. 

One  restriction  we  impose  on  the  language  is  that  every  varialile  that  occurs  anywhere 
in  a  nde  must  occur  in  some  positive  atom  on  the  left  side.  This  implies  that  once  we  ha.ve 
instantiated  these  positive  atoms,  we  have  instantiated  the  entire  rule.  For  example,  the 
rule 

red(x),  not  big{y)  — ^  7'ed{z) 

violates  this  restriction  for  two  reasons;  the  variable  y  from  the  negated  atom  big{7j)  and 
the  variable  z  from  the  right  side  are  not  present  in  the  positive  atom  red{x)  on  the  left 
side.  If  we  attempt  to  apply  this  rule,  it  is  unclear  which  instance  of  bi(j{y)  is  to  be  absent 
from  working  memory  and  which  instance  of  red{z)  is  to  be  added. 

We  do  not  allow  explicit  negation  signs  in  the  working  memory.  This  is  not  an  essential 
limitation.  If  it  is  desired  to  express  that  a.n  atom  p{ti, . .  is  false,  we  can  introduce  a 
new  predicate  symbol  negp,  and  include  negp{ti,. .  .,tA-)  in  the  working  memory,  with  the 
understanding,  to  be  expressed  in  the  theory,  that  negp{i-^^ . . .  ,t};)  is  the  complement  of 

A  I'ule  system  is  an  (unordered)  set  of  rules.  To  apply  a  rule  system  to  a  working  memory, 
we  repeatedly  apply  any  of  the  rules  to  the  working  memory  until  no  rule  is  applicable.  The 
final  working  memory  is  the  result  of  applying  the  system.  Application  of  a  rule  system 
is  noiideterministic;  by  selecting  different  rules,  or  different  instances  of  the  same  rule,  we 
ma.y  obtain  different  results. 

2.3  Explicit  Halting 

Our  systems  halt  only  when  no  rule  is  applicable.  Some  rule-based  languages  offer  an 
explicit  halt  statement:  if  the  special  symbol  H ALT  appears  on  the  right  side  of  a  rule 
that  is  applied,  the  system  will  halt  at  once,  even  if  some  rule  is  applicable.  This  is  a 
convenience  that  docs  not  increase  the  logical  power  of  the  language.  -A.ny  .system  with  the 
halt  feature  can  be  ti-ansformed  into  one  that  beha.ves  the  same  way  without  tire  feature. 
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The  transformed  system  includes  the  negated  atom  not  hall  (that  is,  noi  hali{))  on  the 
left  side  of  each  rule.  If  any  rule  contains  the  special  symbol  JJ  ALT  on  its  right  side,  it  is 
transformed  into  a  rule  with  the  atom  halt  on  its  right  side  instead.  If  such  a  rule  sliould 
fire,  it  adds  the  atom  hall  to  working  memory.  Then  no  rule  will  be  applicable,  and  the 
transformed  system  will  halt,  without  invoking  any  sjiecial  halt  feature. 

For  example,  the  system 

red{x)  — *■  blue[x) 
yelloio{x)  HALT 

with  the  halt  feature  is  transformed  into  the  system 

red{x)^  noi  hall  — ;■  bltte{x) 
yellow{x),  noi  halt  — i-  halt 

without  the  halt  feature.  The  two  systems  behave  the  same  way. 

2.4  Conflict  Resolution  Strategy 

When  several  rules  are  applicable  to  the  same  working  memory,  the  system  invokes  a  conflict 
resolution  strategy  to  choose  a  single  rule  to  be  applied.  Conflict  resolution  strategies  tend 
to  be  complex.  The  spirit  of  the  rule-based  methodology  suggests  that  the  correctness  of  the 
system  should  not  depend  on  the  details  of  the  strategy.  The  choices  of  the  strategy  may 
influence  the  efficiency  of  the  system  or  the  understandability  of  its  execution  sequence,  but 
the  correctness  of  the  final  outcome  should  be  independent  of  these  choices.  Consequently, 
we  have  developed  an  approach  that  will  perform  our  validation  tasks  regardless  of  the 
conflict  resolution  strategy.  If  some  aspects  of  the  strategy  turn  out  to  be  crucial  to  the 
correctness  of  the  system,  they  may  be  expressed  in  an  augmented  system  theory. 

An  exception  is  made  in  the  case  of  the  specificity  aspect  of  the  conflict  resolution 
strategy,  which  does  affect  the  correctness  of  the  system.  According  to  the  specificity 
principle,  a  more  specific  rule  is  to  be  preferred  to  a  more  general  one.  This  principle  allows 
us  to  state  a  rule  in  its  greatest  generality,  n.iid  then  to  add  exceptions  by  introducing  new 
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rules,  without  tlie  need  to  qualify  the  original  rule.  For  example,  in  the  system 
Rule  1  :  bird{x)  — h  bird^x),  fly[x) 

Rule  2  ;  bird{x),penf/uin{x)  — ^  biTd{x),  penguin{x),  negfly{x) 

Rule  3  :  bird{x),penguin{x),inairplane(x)  — ;■ 

bird{x),  penguin{x),  inairplane{x),  fly{x) 

each  rule  is  more  specific  than  the  previous  one,  which  it  qualifies.  It  might  be  erroneous  to 
apply  the  earlier  rule  if  the  later  rule  were  applicable.  For  example,  the  second  rule  should 
not  be  applied  if  the  penguin  is  in  an  airplane,  because  then  the  third  rule  should  supersede 
it.  Thus  the  second  rule  has  the  implicit  condition  not  inair plane{x). 

Because  specificity  has  a  beaiung  on  correctness  concerns,  we  do  want  it  reflected  in 
the  system  theory.  We  achieve  this  by  transforming  rules  so  that  the  implicit  conditions 
imposed  by  the  strategy  are  made  explicit.  For  e.xample,  Rule  2  would  be  transformed  to 

R\de  2' :  bird{x),pengnin(x),  not  inairplane{x)  — i- 
bird^x)^  pengtiin{x),  negfly(x) 

Rule  2'  cannot  be  applied  if  Rule  3  is  applicable.  Rule  1  above  would  be  traiisforined  into 

Rule  l'  :  bird(x),  not  peng^iin{x)^  not  inairplane(x)  — ^  bird{x),  fly(x) 

Rule  1'  cannot  be  applied  if  either  Rule  2'  or  Rule  3  is  applicable. 

This  transformation  has  no  effect  on  the  execution  of  the  system,  but  we  shall  apply 
it  so  that  the  specificity  aspect  of  the  conflict  resolution  strategy  will  be  reflected  in  our 
validation. 

3  The  System  Theory 

In  this  section,  we  describe  how  a  given  rule  system  is  described  in  a  corres])onding  system 
theory,  so  that  questions  about  the  system  may  be  phrased  as  conjectures  within  the  theory. 
Consider  a  rule 


Pi,...,  Pi,  not  Qi,. 


not  Qj  — I-  Ri,...,Ri 
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with  variables  a'l , . . . ,  a;/.-. 

We  define  a  relation  applic{r,  (ti, . . . ,  i/.),  w),  which  holds  if  rule  r  is  applicable  to  worhing 
memory  w  with  variables  .Xi, . .  .,Xf:  instantiated  to  ground  terms  respectively,  by 

the  axiom 

Fi  ik]  €  w 

A 

A 

Pi[tu. .  .,ik]  e  w 

applic{r,{i:^,...,if:),iu)  =  A 

<9i[f-i,-  •  -  ,4]  ^  w 
A 

A 

Qj [«!,..  .,4]  ^  IV 

for  all  ground  terms  and  any  working  memory  w.  Here  is  a  tuple  of 

ground  terms  and  r  is  a  constant  that  names  the  rule.  We  write  .  .,ii]  for  the  result 

of  replacing  each  variable  ,ri, . .  in  P  with  the  corresponding  term  . .  .,4-  In  other 
words,  the  appropriate  instances  of  the  positive  atoms  must  be  present  in  working  memory 
and  the  corresponding  instances  of  the  negated  atoms  must  be  absent.  A  separate  such 
axiom  is  provided  for  each  rule  of  the  system. 

For  example,  for  the  rule 

Rule  1  :  pareni{z,y)^  noi  male{x)  — r  par eni.{x^y),  mother {x^y) 
we  provide  the  axiom 

applic{rulel,  {s,  i),w)=  \pareni{s,  i)  6  v)  A  m.ale{s)  ^  tn] . 

Note  that  each  predicate  symbol  in  a  rule  is  represented  by  a  function  symbol  in  the 
system  tlieory.  Thus,  parent  and  male  are  function  symbols. 
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We  also  define  a  function  apply[r,  {ii, . . whose  value  is  the  result  of  applying 
the  rule  r  to  working  memory  w  with  variables  instantiated  to  ground  terms 

, . . . ,  if;,  by  the  axiom 

if  app[ic{r,{U,...,it;),w) 

then  apply{r,  {ti,...,  4->,  w)  ^  tu  -  Pi[ii,..., 

-  Pi[ty,--;h] 

+  -  • -,4-] 

+  •  •  •,  4-]- 

Here  w  —  u  and  tu  +  u  are  the  results  of  deleting  the  element  u  from  the  set  w  and  adding 
u  to  w,  respectively. 

For  example,  for  Rule  1,  we  provide  the  axiom 

if  applic{rfilel,{s,l),w) 

then  ap})ly{rulel,  {s,i),w)  =  IV  —  pareni{s,L) 

+  pareni{s,i) 

+  mother{s,l). 

When  we  leave  a  variable  free,  we  mean  it  to  have  implicit  universal  quantification.  Also, 
we  use  our  vocabulary  to  indicate  the  sorts  of  the  objects  involved.  For  example,  the  above 
axiom  is  to  apply  to  any  working  memory  w  and  all  ground  terms  $  and  t. 

Note  that  when  a  positive  atom  occurs  on  both  the  left  and  the  right  sides  of  the  rule, 
the  corresponding  term  is  first  deleted  from  and  then  added  to  the  set  tv  in  the  apply  axiom. 
Because  the  tei'm  is  certain  to  occur  in  the  set,  this  will  always  leave  the  set  the  same.  For 
example,  in  the  apply  axiom  for  Rule  1,  the  term  parent{s,t)  is  first  deleted,  then  added. 
To  simplify  the  axioms  (and  the  corresponding  proofs),  these  operations  will  be  omitted. 
The  apply  axiom  for  Rule  1  will  actually  read 

if  ap])lic{rulel,  {s,i),v))  then  apply[rulel,{s,L),tv)  —  tv  +  motheifi). 
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The  following  axiom  tells  ns  that  if  a  rule  is  applicable  to  a  working  memory,  that  rule 
must  be  one  of  the  rules  of  the  system: 

if  applic(r,t,w) 
ihen  r  =  rule\  \J  •  --V  r  =  rulen, 
where  i  is  a  tuple  of  groiuid  terms. 

More  complex  versions  of  this  axiom  may  be  substituted  if  one  desires  to  express  more 
subtle  aspects  of  the  conflict  resolution  strategy. 

We  shall  say  that  the  entire  system  is  applicable  to  a  working  memory  w,  denoted  by 
appl{w),  if  some  rule,  with  some  instantiation,  is  applicable.  This  is  expressed  by  the  axiom 

appl{w)  =  (3?-,  t)ftpp/fc(7',t,  w). 

A  working  memory  w  to  which  no  rule  is  applicable,  that  is,  -lappl^w)^  is  called  a  final 
working  memory. 

Tliis  translation  of  rules  into  axioms  depends  on  our  formulation  of  the  rule  language; 
the  translation  mechanism  for  other  languages  will  differ  slightly. 

3.1  Histories 

A  history  is  a  description  of  a  finite  initial  segment  of  a  possible  computation  of  the  system. 
In  the  theory,  a  history  is  a  finite  tuple  of  pairs 

Each  I'i  is  the  rule  applied  at  the  stage  of  the  computation.  Each  ti  is  a  tuple  of  ground 
terms  indicating  how  the  variables  of  the  rule  are  instantiated  at  the  stage. 

A  history  h  =  ((I'j,  ),...,  (I'm ^n))  is  applicable  to  a  working  memory  w,  denoted  by 

liisi[h,xv),  if  there  is  a  finite  sequence  of  working  memories 


where  =  wi,  such  that 


=  apply(ri,ti,Wi): 
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that  is,  each  memory  is  obtained  from  the  previous  one  by  applying  the  corresponding  rule 
from  the  history.  This  is  expressed  by  the  axioms 


i)  •  h,  w)  =  applic(r,  t,  vj)  A  h{si(h,  apply{T,  t,  w)) 

for  all  working  memories  w,  rules  r,  tuples  of  ground  terms  t,  and  histories  h.  Here  (r,  t)  •  h 
is  the  history  obtained  by  inserting  the  pair  {r,t)  at  the  beginning  of  the  history  h. 

The  result  sys{h,xo)  of  applying  an  applicable  history  h  to  a  given  working  memory  v) 
is  expressed  by  the  axioms 

sys{{),%o)  -  vj 

i f  i)  •  h,  w)  then  sys{{i\  /)  •  h,  w)  =  sys{h,  apply{r,  i,  u;)). 

The  second  axiom  states  that  the  result  of  applying  a  nonempty  history  is  the  same  as  that 
of  applying  its  first  rule  and  instantiation,  and  then  applying  the  remainder  of  the  history. 
The  result  is  itself  a  working  memory. 

Note  that  a  history  describes  an  initial  segment  of  a  computation  of  a  rule  system, 
not  necessarily  a  full  computation;  more  rules  may  Ire  applicable  to  the  resulting  working 
memory.  We  say  that  li  is  a  terminating  history  starting  from  w,  denoted  by  Ler[li,w),  if  h 
is  applicable  to  w  and  results  in  a  final  working  memory.  This  is  expressed  by  the  axioms 

ter{{)jw)  =  ~'appl{w) 

t€r{{r,i)  •  h,w)  =  applic{r,i,w)  A  ier[Ii,apply{r,i,w)). 

It  can  be  established  that 

ter(/i,'w)  =  A  -iappl(sys(h,%o)). 

3.2  Finite  Sets  and  Unique  Names 

Because  we  use  finite  sets  of  expressions  to  represent  working  ineniory,  it  is  necessary  to 
incorporate  the  theory  of  finite  sets  into  our  system  theory.  In  particular,  we  include  axioms 
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that  describe  the  set  additioji  function  w  +  v  and  the  set  membership  relation  u  G  w: 

u  ^  {} 

u  G  n;  + 

i f  u  G  then  u  G  lu  +  v 
if  u  /  V  then  if  u  ^  w  +  v  ilien  u  G  w. 

For  the  set  deletion  function  w  —  v  we  have 

V  ^  W  —  V 

if  u  £  w  —  V  then  u  G  w. 

We  include  a  general  well-founded  induction  principle,  described  in  the  next  subsection, 
which  applies  to  finite  sets  and  finite  histories  as  well. 

Properties  of  tuples,  for  reasoning  about  histories  and  about  tuples  of  ground  terms,  are 
also  included  but  will  not  be  presented  here.  Theories  of  finite  sets  and  tuples  are  described 
more  fully  in  Manna  and  Waldiiiger  [10]. 

Although  it  may  seem  pedantic,  we  must  include  axioms  that  tell  us  that  distinct  func¬ 
tion  symbols  correspond  to  distinct  predicate  symbols  in  working  memory.  For  example, 
recl{s)  and  blue{t)  cannot  stand  for  the  same  atom.  This  is  expressed  by  the  axiom 

redfs)  /  blu€{t). 

We  must  provide  such  an  axiom  for  each  pair  of  function  symbols  corresponding  to  predicate 
symbols  in  working  memory. 

We  must  also  provide  an  axiom  stating  tliat  if  two  terms  are  distinct,  they  cannot  be 
made  identical  by  applying  any  of  tlie  predicate  symbols  from  tlie  working  memory;  e.g., 
for  the  predicate  symbol  red,  we  have 

if  red{ti)  =  redft-if)  then  /.j  =  t^. 

A  similar  axiom  is  provided  for  each  function  symbol  corresponding  to  a  predicate  symbol 
from  working  memory. 


3.3  Well-Founded  Induction 


Many  proofs  require  use  of  an  induction  principle.  VVe  use  well-founded  induction  (also 
called  Noetherian  induction).  Tliis  principle  lias  the  following  form. 

To  prove  a  sentence 

(Vu;)P[w] 


prove  the  inductive  step 


(Vw) 


i f  (Viu')  [if  w'  -<  w  then  P['n;']] 
then  P[wj 


Here  -<  is  a  well-founded  relation,  that  is,  one  that  admits  no  inlinite  decreasing  sequences 


Wi  y  W2  >  W3  y  •  ■  • 


We  provide  definitions  of  many  known  well-founded  relations.  For  example,  the  proper 
subset  relation  is  known  to  be  well-founded  over  the  finite  sets  because  there  are  no  infinite 
sequences  of  finite  sets 

Wi  D  W2  D  103  J 

We  also  include  as  lemmas  other  properties  of  the  proper  subset  relation,  e.g., 

if  u  E  'Jv  then  w  —  u  C  w. 

Well-founded  relations  over  the  tuples  are  also  provided. 

4  Validation  Conjectures 

Many  validation  tasks  may  be  phrased  as  conjectures  within  the  system  theory;  if  we  can 
establish  the  validity  of  the  conjecture  in  the  theory,  we  have  carried  out  the  validation 
task. 
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For  example,  suppose  we  wisli  to  determine  whether,  for  the  given  rule  system,  big,  red 
objects  will  be  painted  yellow.  We  may  plirase  this  tiisk  as: 

if  red(t.)  E  w  A 
bi(j{i)  6  w  A 
ier(h,  v)) 

then  yelloxv{t)  E  sys{h.n}) 

If  we  can  prove  this  sentence  in  the  system  theory,  we  have  sliown  tliat  tim  system  satisfies 
tile  condition. 

Note  that  the  sentence  does  not  establish  termination  of  the  system,  but  only  that  if  a 
history  does  terminate,  tlie  condition  will  be  satisfied.  To  show  that  the  system  does  always 
terminate,  it  suffices  to  establish  the  following  terminnlion  condition: 

if  apj)lic{r,  i,w)  then  apply{r,  f,  in)  -<  xu 


(Vwj/i,  t) 


for  some  well-founded  relation  In  other  words,  we  show  that  each  ap])licable  rule  reduces 
the  size  of  working  memory  with  respect  to  some  well-founded  relation.  Because  well- 
founded  relations  do  not  admit  infinite  decreasing  sequences,  this  means  we  must  ultimately 
reach  a  working  memory  to  which  no  rule  is  applicable,  i.e.,  a  final  working  memory. 

In  our  examples,  we  require  the  user  to  provide  a  well-founded  relation  for  the  termina¬ 
tion  proof.  For  example,  the  user  might  define 


Wi  ^  ttJ2  = 


(Vi)  [if  red{i)  E  xui  then  x-cd{i)  6  uis] 
A 


(3i')  [red{t‘)  E  A  red{i')  ^  rui] 


Therefore,  with  respect  to  -<,  if  one  working  memory  is  less  than  another,  it  has  fewer 
red  objects.  This  is  well-founded  because  working  memories  are  finite.  (We  could  define 
a  similar  relationship  in  terms  of  the  number  of  red  objects  in  working  memory,  but  this 
would  require  reasoning  about  nounegative  integers,  as  well  as  sets,  in  the  proof.)  A  more 
ambitious  effort,  which  we  have  not  yet  attempted,  would  require  the  system  to  discover 
the  well-founded  relation  as  part  of  the  proof  process. 
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If  we  fail  to  prove  that  all  red,  liig  objects  will  be  painted  yellow,  we  may  attem])t  to 
establish  the  opposite,  namely,  that  some  red,  big  objects  will  not  Ije  painted  yellow.  This 
can  be  established  by  proving  the  negation  of  the  original  conjecture,  i.e.,  that 

red{t)  €  ni  A 
big{i)  ^  10  A 
ier^li,  w)A 

yelloiu{t)  ^  sys{li,w) 

Proving  this  conjecture  will  establish  the  falseness  of  the  original  condition.  If  we  restrict 
a  proof  to  be  sufficiently  constructive,  we  may  extract  from  the  proof  a  description  of  the 
objects  whose  existence  it  establishes.  From  this  proof,  we  may  extract  a  description  of  a 
case  in  which  the  condition  fails  to  hold.  In  particular,  we  obtain  a  description  of  an  initial 
working  memory,  a  terminating  history,  and  an  object  such  that  the  object  is  initially  big 
and  red,  but  e.\'ecuting  the  history  will  produce  a  final  working  memory  in  which  the  object 
is  not  painted  yellow. 

Suppose  we  cannot  prove  termination  and  we  suspect  that  our  system  sometimes  fails 
to  terminate.  To  prove  this,  we  must  provide  a  description  of  a  possible  infinite  execution 
history,  in  the  form  of  three  functions,  r,  t,  and  to,  which  compute  the  rule,  instantiation, 
and  working  memory,  respectively.  These  functions  must  satisfy  the  property 

a7jp/fc(7‘(f),t(i),  w(i))A 
apply{r{i),t{i),to{i))  =  tv{i  +  1) 

for  all  integers  i  >  1.  We  have  not  yet  experimented  with  proving  no ntermi nation. 

If  we  want  to  establish  that  a  particular  rule,  say  Pule  1,  can  fire,  we  may  prove  the 
conjecture 

(3n),  h,  t)[hisL{li,  to)  A  appiic{rtilel,i,  sys{h,  m))]. 

If  we  restrict  the  proof  to  be  sufficiently  constructive,  we  may  obtain  descriptions  of  the 
initial  working  memory  to,  history  h,  and  instantiation  t,  such  that  executing  h  in  initial 
working  memory  tv  will  ]iroduce  a  working  memory  in  which  Rule  1  is  applicable,  with 


(3w,  Ii,i) 


IS 


instantiation  t.  Proving  the  negation  of  the  above  conjecture  will  establish  that  Rule  1  is 
unreachable,  i.e.,  cannot  be  executed  under  any  circumstances. 

The  notion  of  consistency  depends  on  an  application  domain.  Our  rule  language  does 
not  include  explicit  negation,  but  it  may  include  predicate  symbols  that  are  understood 
to  be  mutually  inconsistent.  We  may  expect,  for  example,  that  an  object  cannot  be  both 
red  and  blue,  or  that  the  predicate  symbol  netjp  is  to  be  the  complement  of  the  predicate 
symbol  p. 

If  we  want  to  show  that  our  system  can  never  produce  an  object  that  is  simultaneously 
red  and  blue,  we  may  attempt  to  prove 

i f  hist{h,  w 

then  ->  [red(i)  6  3ys{h,w)  A  bhie{i)  €  sys(/i.,uj)] 

The  above  conjecture  implies  that  an  object  cannot  be  both  red  and  bine  at  any  stage 
of  the  computation.  If  we  are  only  concerned  with  the  final  state  of  the  computation,  we 
may  prove 

if  ter{h,w 

then  ->  [red{t)  €  sys{h,7u)  A  blue(t)  €  sys{h,rv)] 

If  we  can  prove  the  negation  of  either  of  the  above  conjectures,  we  have  established  that 
the  system  can  produce  an  inconsistency,  in  either  an  intermediate  state  or  a  final  state, 
respectively.  Restricting  the  proofs  to  be  sufficiently  constructive  will  enable  us  to  extract 
a  description  of  how  the  inconsistency  can  occur. 

5  Example:  The  Billing  Category  System 

To  illustrate  the  formation  of  a.  system  theory,  we  adapt  an  example  from  a  standard 
expert-systems  text  (the  customer-lnlling  example  from  Brownston  et  al.[3]).  The  system 
is  to  assign  each  of  a  fixed,  finite  pool  of  customers  to  a  billing  category,  either  normal  or 
priority,  depending  on  the  history  of  the  customer.  The  rules  of  the  system  are  as  follows; 

Rule  1  :  (jood{x).  not  setfx)  — ^  yood{x).  sei{x),  priority{x). 


(Vw,/i,  t) 


(Vrn,  li,  t) 
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Tliat  is,  if  the  category  of  a  good  customer  has  not  been  set,  assign  the  customer  to  the 
priority  category. 

Rule  2  :  bad{x),  not  sei(x)  — >  bad{x)^  sei{x),normal{x). 

That  is,  if  tlie  category  of  a  bad  customer  has  not  been  set,  assign  the  customer  to  the 
normal  category. 


Rule  3  :bad{x),  not  sel{x),long[x)  — >  bad{x)^sei{x),long{x),]}riority[x). 

That  is,  if  the  category  of  a  bad  but  long-term  customer  has  not  been  set,  assign  the 
customer  to  the  priority  category.  Note  that,  by  the  specificity  principle.  Rule  3  isjntended 
to  supersede  Rule  2  when  both  are  applicable;  that  is.  Rule  2  is  not  meant  to  apply  to 
long-term  customers. 

5.1  The  Rule  Axioms 

These  rules  are  represented  by  the  following  axioms  in  the  system  theory. 

if  applic{r,i,w)  then  r  —  ridel  V  ?’  =  rule'2  V  ?•  =  ruleZ. 

In  other  words,  the  only  rules  that  can  be  applicable  to  a  given  customer  i  are  Rule  1, 
Rule  2,  or  Rule  3. 

Axioms  for  Rule  1: 

applic{rulel,  i,  w)  =  good{i)  £  w  A  set[i)  ^  w 

Note  that  because  the  rules  have  only  one  variable,  we  simplify  the  axioms  by  using  t,  rather 
than  {i),  throughout. 

if  applic{rulel,t,w)  then  apply{rulel,i,  lu)  =  u>  -\-  seift)  +  priority{t) 

Because  the  atom  good{x)  occurs  on  both  sides  of  Rule  1,  tlie  covrespoucling  term  good(i.) 
is  neither  deleted  nor  added  by  the  axiom. 
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Axioms  for  Rule  2: 


applic{rule2,t,iu)  =  bad{t)  6  w  A  lon(j{i)  ^  lu  A  set{i)  ^  lu 

Note  that  we  include  in  tl\e  applicability  axiom  for  Rule  2  the  condition,  implied  by  the 
specificity  principle,  that  the  rule  should  not  be  applied  to  long-term  customers. 

if  applic{rule2,i,w)  then  apply[rule2,t,w)  =  u;  +  set[t)  +  normal{i) 

Axioms  for  Rule  3: 

applic{ruled,t,xu)  =  badfl)  G  lu  A  long{t)  6mA  sei{t)  ^  w 

if  applic{rxde5,  t,  w)  then  applxjfrxileZ,  t,  w)  =  w  +  s€t{t)  +  prioriUjff) 

The  other  axioms  of  the  system  theory  are  the  same  from  one  system  to  the  next. 


5.2  Conjectures:  A  Scenario 


Suppose  we  wish  to  determine  whether  a  good  customer  will  always  be  placed  in  the  priority 
category.  Then  w'e  may  conjecture 


(ViUj/t,  t) 


i f  t€r{h,  lu)  then 


i f  <jood{i)  6  w 

then  prioritxjft)  6  sys{h,  w) 

In  fact,  we  cannot  prove  the  above  conjecture.  We  can,  however,  prove  its  negation 


(3m,  /i,  t) 


ter{h,  m)A 
good{t)  €  mA 
priority(t)  ^  sys{h^  m) 


If  we  restrict  the  proof  to  be  constructive,  we  may  extract  a  description  of  the  initial  worlcing 
memory, 

m  :  {good{t),  seifi)] 


and  the  history 


the  empty  history.  (The  variable  i  is  not  instantiated  during  tlie  proof,  so  it  can  be  replaced 
by  any  ground  term  that  denotes  a  customer.)  In  other  words,  no  rule  is  applicable  to  the 
initial  working  memory  {good{i),  sei{i)},  because  customer  I  has  been  marked  as  if  his 
billing  category  has  already  been  set.  Therefore,  the  final  working  memory  s7/s(/?.,  lu)  is  the 
same  as  the  initial  working  memory  m,  and  priority{t)  ^  lu. 

We  attempt  to  refine  our  conjecture  accordingly.  We  speculate  that  if  a  good  customer 
has  no  set  billing  category,  he  will  ultimately  be  placed  in  the  priority  category.  We  attempt 
to  prove 

if  ter{k,w) 

(Vm,/i,t)  then  if  good{i)  ^  w  A  sei{i)  0  m 
then  priority{t)  e  sys{!i,  w) 

Again  we  fail  to  prove  this,  but  succeed  in  proving  its  negation.  If  the  proof  is  restricted  to 
be  constructive,  we  may  extract  the  (inconsistent)  initial  working  memory 

w  :  {bad{i),good{i)} 

and  the  one-element  history 

h  :  {{Tule2,  i)). 

This  example  has  again  defied  our  expectations.  Because  customer  t  is  bad  as  well  <is  good 
(and  not  a  long-term  customer).  Rule  2  can  be  applied,  producing  the  final  working  memory 

sys{h,w)  :  {bad{i),good{t),sei{i),normal{i)}. 

In  other  words,  good  customer  i  has  not  been  put  into  the  priority  category. 

This  scenario  illustrates  the  pitfalls  we  may  face  in  formulating  a  specification  for  a 
rule-based  system  (or  any  system).  It  also  illustrates  how  a  proof  system  may  help  us  break 
through  some  precojiceptions.  With  further  experimentation,  we  may  attempt  to  formulate 
and  ])rove  a  full  specification  for  a  rule  system,  which  characterizes  its  intended  behavior. 
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For  the  billing  category  system,  we  propose  the  following  conjecture: 

[^oof/(/,)  G  w)lbad{t)  G  n;]A 
set{t)  ^  wA 
priority{t)  ^  \uA 
normal{t)  ^  w 

if  ter(li,w) 

then  [priority{t)  G  sys[li,w)  =  yood(i)  G  w  V  [ony{t)  G  rn]A 
[7i07‘mal(i)  G  S7/s(/r,  ru)  =  bad{i)  G  'w  A  lony{i)  ^  mjA 
sei{t)  G  sys(h,  w)A 
[yood{t)  G  sys{Ii,'w)  =  yood{i)  G  ia'JA 
[bad{t)  G  sys{k,  w)  =  bad(t)  G  w]A 
[lony(t)  G  sys{h,w)  =  lony{t)  G  iw] 
for  all  customers  t  and  working  memories  w.  In  other  words,  we  suppose  that  initially  each 
customer  is  cither  good  or  bad,  but  not  both  (V  is  exclusive  or).  Initially  no  customer  has 
had  his  billing  category  set,  and  no  customer  is  in  either  normal  or  priority  category.  Then 
for  each  terminating  history,  we  require  that  the  customers  in  the  final  priority  category 
be  those  that  are  initially  good  customers  or  long-term  customers.  Customers  in  the  final 
normal  category  must  be  those  that  are  initially  bad  customers  and  not  long-term  customers. 
Every  customer  must  have  his  final  billing  category  set.  Furthermore,  we  may  expect  that 
customers  in  the  final  good-customer,  bad-customer  and  long-term  customer  categories  are 
the  same  as  those  that  were  in  those  categories  initially. 

The  above  conjecture  relates  the  initial  and  final  working  memories.  For  the  proof 
to  succeed,  we  must  generalize  the  theorem  to  relate  the  intermediate  and  final  working 
memories.  The  generalized  conjecture  implies  the  above  conjecture  as  a  special  case.  We 
have  not  yet  proved  the  above  conjecture. 

Termination  of  the  system  must  be  proved  separately,  by  establishing  the  usual  termi- 


iheii  (V/i) 


if  (Vt) 
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nation  condition 


if  applic{r,i,w) 
then  apply{r,  i,to)  -<  w 

for  some  well-founded  relation  In  tliis  case,  the  well-founded  relation  may  be  defined 

by 


(V<)  [i /  sei{i)  €  W2  then  sei{i)  £  Wi] 


W\  -<  VJ2  = 


A 


(3/.')  [set(t/)  ewi  A  sei(i')  ^  W2]  J 

In  other  words,  with  respect  to  ■<,  one  working  memory  is  less  than  another  if  it  has 
more  customers  with  set  billing  category.  This  is  well-founded  because  there  are  only  a 
finite  number  of  customers. 


6  The  SNARK  System 

To.  prove  validation  conjectures,  a  theorem  prover  requires  an  unusual  combination  of  fea¬ 
tures.  In  particular,  it  must 

•  Prove  sentences  in  full  first-order  logic. 

•  Deal  expeditiously  with  equality  and  ordering  relations. 

•  Prove  theorems  by  mathematical  induction. 

•  Handle  finite  sets  and  tuples. 

•  Restrict  proofs  to  be  sufficiently  constructive  to  allow  information  extraction  when 
necessary. 

•  Prove  simple  theorems  without  human  assistance. 

While  some  existing  theorem  provers  excel  in  certain  of  these  areas,  they  are  typically 
deficient  in  others.  The  Argoniie  system  [12],  for  example,  is  proficient  at  full  first-order 
logic  with  equality,  but  has  no  facilities  for  jnoof  by  induction.  The  Boyer-Moore  theorem 
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prover  [2]  specializes  in  proof  by  induction,  but  does  not  allow  full  first-order  quantification. 
The  Nuprl  system  [6]  is  certainly  expressive  enough — it  allows  full  quantification  and  proof 
by  induction — but  is  not  geared  to  finding  proofs  automatically.  Furthermore,  it  relies 
entirely  on  a  constructive  logic  that  may  prove  cumbersome  when  no  information  needs  to 
be  extracted  from  the  proof. 

For  these  reasons,  we  have  been  developing  a  new  theorem  prover,  SNARK,  for  appli¬ 
cation  in  software  engineering  and  artificial  intelligence.  SNAllK  is  especially  appropriate 
for  the  validation  of  rule-based  systems. 

SNAIIK  operates  fully  automatically  and  uses  an  agenda  to  order  inference  operations. 
Similarly  to  the  Argonne  system,  SNARK  attempts  to  compute  the  deductive  closure  of  a 
set  of  formulas.  The  user  selects  the  inference  operations  and  starting  formulas  to  be  used. 
Agenda  elements  are  formulas  in  the  set  of  support  to  be  ojierated  upon  by  all  selected 
inference  rules,  and  are  ordered  by  symbol  count. 

The  most  important  inference  operations  available  in  the  current  system  are  binary 
resolution  and  paramodulation.  These  rules  allow  SNARK  to  deal  with  predicate  logic  with 
equality,  which  underlies  the  system  theory  for  rule-based  systems.  We  have  used  extended 
versions  of  these  inference  rules  that  are  applicable  to  noiiclausal  formulas  as  well  as  clauses. 
Ilyperresolution  can  be  simulated  by  control  restrictions  on  the  use  of  binary  resolvents. 
Both  clausal  and  noiiclausal  subsumption  are  available  to  eliminate  redundant  formulas. 

Formulas  can  be  simplified  by  user-given  or  derived  equalities  or  equivalences.  Innermost 
or  outermost  simplification  strategies  can  be  specified.  Derived  equalities  can  be  oriented 
automatically  by  Knuth-Bendix  or  recursive  decomposition  simplification  orderings.  Truth- 
functional  simplification  is  accomplished  by  rewriting  rules,  which  makes  it  easy  to  add  new 
connectives  and  their  simplification  rules. 

SNARK  can  use  either  nonclausal  formulas  or  the  more  restrictive  clauses.  If  clauses 
are  to  be  used,  SNARK  can  automatically  translate  more  general  formulas  to  clauses.  Even 
if  clainses  are  primarily  used,  translation  of  formulas  to  clauses  is  not  required  to  be  done 
only  at  the  beginning  of  the  proof.  Rewrites  can  specify  that  a.n  atomic  subformula  of  a 
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formula  be  rewrilten  to  a  formula;  the  result  of  rewriting  may  be  a  iionclausal  formula  that 
is  later  simplified  to  clause  form.  For  example,  the  rewrite 

u^w  +  v  =  u  =  vV  11  Ew 

would  result  in  the  clause  a  ^  s  +  x  V  C  being  rewritten  to  -i(a  =  x  V  a  €  s)  V  C,  which 
could  be  replaced  by  two  clauses. 

Efficient  formula-  and  term-indexing  methods — a  choice  of  patli  indexing  or  discrimina¬ 
tion-tree  indexing — are  used  to  efficiently  retrieve  the  relevant  formulas  or  terms  for  infer¬ 
ence,  subsumption,  and  simplification  operations.  Efficient  indexing  is  essential  for  solving 
difficult  problems  that  require  derivation  of  a  large  number  of  results. 

SNARK  uses  sorted  logic  to  efficiently  represent  the  information  that  certain  classes 
of  objects  being  manipulated  are  disjoint.  In  the  examples  of  this  paper,  several  sorts  are 
used:  rules,  working  memories,  working  memory  elements,  customers,  history  lists,  and  the 
pairs  that  are  history  list  members. 

SNARK  supports  the  use  of  special  unification  (and  subsumption  and  equality)  algo¬ 
rithms.  Associative-commutative  subsumption  is  widely  used  for  truth-functional  simplifi¬ 
cation,  and  commutative  matching  is  used  to  efficiently  implement  symmetry  of  the  equality 
relation. 

Although  at  an  early  stage  of  development,  SNARK  has  already  been  useful  in  proving 
properties  of  rnle-based  systems,  including  those  indicated  in  the  scenario  (Section  5.2). 

7  Summary  and  Plans 

Our  work  suggests  that  deductive  methods  are  appropriate  to  support  testing  and  other 
validation  tasks,  besides  verification,  for  rule-based  systems.  Preliminary  results  in  applying 
the  new  deduction  system  SNARK  to  sample  rule-based  systems  have  been  promising. 
By  restricting  the  system  to  be  sufficiently  constructive,  we  have  been  al)]e  to  extract 
information  other  than  simple  yes/no  answers  from  proofs.  We  have  found  tliat  a  method 
for  formulating  specifications  by  proposing  a  series  of  conjectures  is  appropriate  to  rule- 
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based  systems. 

We  intend  to  develop  the  system  theory  to  apply  to  more  realistic  rule  languages  and 
to  extend  SNARK  to  more  complex  rule  systems  and  more  sophisticated  properties  and 
conjectures.  The  extension  will  be  carried  out  by  introducing  inference  rules  targeted  to  the 
application  (e.g.,  rules  for  reasoning  about  sets  and  ordering  relations),  strategic  deduction 
(e.g.,  special  treatment  for  inductive  proofs),  interactive  controls,  and  parallel  search  for 
proofs. 
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